put the cross-language scoreboard up front, and say why both backends exist - #597
Merged
Conversation
… exist two things a reader had to assemble themselves. the first is a straight comparison. the numbers were spread across five sections and three documents, so docs/performance.md now opens with two tables — coordination and compute — that put pith next to go, rust, and zig on every benchmark this repo runs, with the backend named on the rows where it matters. the summary underneath is three sentences: green beats rust and zig on coordination and beats go pinned to one worker, spawn is ~2x go at go's memory, and compute is competitive with go and well behind rust and zig with string building the remaining gap. the second is which backend to use, which the docs never actually answered. green wins every measured shape, so the interesting half is why os threads are still there, and it is not inertia. blocking calls stall a green worker and everything pinned to it — the reactor covers sockets, but dns, file i/o, and native calls do not yield — where on os threads a blocking call costs only the task making it. the reactor is also epoll-only, so macos and the bsds run green with no reactor at all and block a worker on every socket wait; "green by default" is a linux-server claim rather than a universal one. and preemption is free on os threads but needs a build flag on green. there is a fourth reason that matters to the repo rather than to a user, and it is worth writing down: the os-thread backend is the oracle the green one is checked against. verify-green-corpus diffs the whole corpus under green against the output os threads produce, which is how the single-worker deadline bug surfaced. two implementations that have to agree is a testing asset worth keeping past the point where one is faster.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
summary
two things a reader had to assemble themselves.
the first is a straight comparison against other languages. the numbers were
spread across five sections and three documents, so
docs/performance.mdnowopens with two tables — coordination and compute — putting pith next to go,
rust, and zig on every benchmark this repo runs, with the backend named on the
rows where it matters. the three-sentence summary underneath: green beats rust
and zig on coordination and beats go when pinned to one worker, spawn is ~2x go
at go's memory, and compute is competitive with go and well behind rust and zig
with string building the remaining gap.
the second is which backend to use, which the docs never actually answered.
green wins every measured shape, so the interesting half is why the os-thread
backend is still there, and it is not inertia:
reactor covers sockets, but dns, file i/o, and native calls do not yield. on
os threads that call costs only the task making it.
reactor, so green there blocks a worker on every socket wait — "green by
default" is a linux-server claim, not a universal one.
verify-green-corpusdiffs the corpus under green against os-thread output, which is how the
single-worker deadline bug surfaced.
the first two of those were missing from
docs/limitations.md, so they areadded there as gates on the eventual default flip.
what was tested
make docsite-check(docsite output matches the golden files). docs only — nocode, no examples touched.